The efficient development of reliable software for reactive systems, which controllers of all types are, is nowadays a primary aim. FIG. 1 shows a schematic layout of a system comprising a controller and a process to be controlled. The controller must be designed in such a way that the process assumes only admissible states. The controller is fed input values, for example sensor values, at the inputs, these values being referred to as input states below. At the outputs, the controller outputs output values, referred to below as output states, which influence the process in such a way that it can assume only the admissible states.
During the programming of such memory-programmable controllers (programmable logic controllers), the following prescriptions must be observed in each case:
The mode of operation of the devices or processes to be controlled--that is to say what is effected by each individual output state of the controller, and how the sensor values which are supplied to the controller are to be interpreted. PA0 The function to be implemented by the controller; for example movement sequences. PA0 If appropriate, any restrictive safety conditions; for example if specific combinations of states or specific geometric configurations are to be avoided, specific actuators must only be activated if associated prior conditions (interlocks) are satisfied, etc.
These prescription are in each case available in a different, mostly informal, form. The technical problem is then to program a controller in such a way that it corresponds to the prescriptions.
By contrast with control engineering tasks, in which the theory knows about specific (standard) control algorithms, depending on process models, discrete control tasks have to be newly programmed in each case.
The programming of memory-programmable controllers is nowadays carried out in the manner in which the programmer defines the logical combinations according to which the output states are determined from the input states and the program states.
In order to program sequences there exist appropriate constructs of programming languages, in order to describe so-called step chains and parallel sequences. In each case, however, it is up to the programmer to ensure compliance with the function and the safety conditions. In other words, the relationship between the program and the abovementioned prescriptions is not documented explicitly.
One problem in the case of this procedure is the susceptibility to error, for even in the case of medium-sized systems the multiplicity of the possible system states is virtually incomprehensibly large; this means that cases are almost always overlooked, and programs have to be rewritten, with considerable effort, during the commissioning.
Even more serious is the problem that each rewrite, be it because of an error, because of changed environmental conditions or because of new requirements, impacts on the entire software--that is to say there is no mechanism which keeps the effects of a change local or else marks only those points impacted by a change.